SQL Server 2008: Security and User Administration - Managing SQL Server Logins

Using SSMS to Manage Logins

The visual tools for managing logins in SSMS are accessible via the Object Explorer. You need to expand the Security node in Object Explorer and right-click the Logins node. Then you select the New Login option, and the new login screen, shown in Figure 1, appears.

Figure 1. Creating a login in SSMS with Windows Authentication.

The default authentication mode for a new login is Windows Authentication. If you want to add a login with Windows Authentication, you need to type the name of your Windows user or group in the Login Name text box. You can also click the Search button to search for Windows logins. In either case, the login entered for Windows Authentication should be in the form <DOMAIN>\<UserName> (for example, mydomain\Chris) or in the form [email protected].

With Windows Authentication, you have an option to restrict access to the server for the new login when it is created. If you select Deny Server Access, a command to deny access to SQL Server is issued immediately after the login is created (for example, DENY CONNECT SQL TO [DBSVRXP\Chris]). This option can be useful for staging new logins and waiting until all the appropriate security has been applied prior to allowing the login to access your SQL Server instance. After you completing the security setup for the login, you can select the login properties and choose the GRANT SERVER ACCESS option.

You can use the same new login screen shown in Figure 1 to add a login with SQL Server Authentication. Again, you need to provide a login name, but with the standard SQL Server login, there is no domain associated with the user. The login is independent of any Windows login and can be named as desired. The login and password for SQL Server Authentication are stored and maintained in SQL Server.

When SQL Server Authentication is selected, several options related to passwords are enabled. These options, as shown in Figure 2, include Enforce Password Expiration, Enforce Password Policy, and User Must Change Password at Next Login. These options are all associated with a more rigid password policy. They are similar to options available with Windows accounts and provide a more robust security solution for SQL Server logins. The catch is that the new password options are enforced only on the Windows 2003 Server operating system and versions above. You can select these options when running SQL Server on a machine that has an operating system that is lower than Windows 2003 Server, but the hooks between SQL Server and the operating system are not in place to enforce the password policy.

Figure 2. Creating a login in SSMS with SQL Server Authentication.

[View full size image]

The next set of options on the General page of the new login allows you to map the login to a certificate, asymmetric key, or credential. The certificate and asymmetric key selections allow you to create a certificate-mapped login or an asymmetric key-mapped login. A certificate-mapped login and an asymmetric key-mapped login are used only for code signing and cannot be used to connect to SQL Server. If these options are used, the certificate or asymmetric key must exist on the server before you map the logins to them. The capability to map the login to a credential on the General page is new to SQL Server 2008. This option simply links the login to an existing credential, but its capabilities may be expanded.

The default database and default language are the final options located on the General page of the new login screen. These options are available regardless of the authentication method selected. The default database is the database that the login will connect to by default. The master database is selected, but it is generally not the best database to select for your default. You should choose the default database that your login will use most often and avoid using any of the system databases as your default. This helps prevent database users from executing statements against the wrong database, and it also removes the step of having to change the database every time the user connects. You should make sure that the login is given access to whatever database you select as the default. (The Database Access page is discussed later in this chapter.)

The default language determines the default language used by the login. If no default language is specified and the <default> entry is left in the Language drop-down, the server’s default language is used. The default language for the server can be retrieved or set by using the sp_configure system stored procedure. The language selection affects many things, including date formats, month names, and names of days. To see a list of languages available on the server and the related options, you use the sys.syslanguages catalog view.

The new login screen has four other pages available for selection when creating your new login: Server Roles, User Mapping, Securables, and Status. The Server Roles page allows you to select one or more fixed server roles for the login to participate in. Figure 3 shows the new login screen with the Server Roles page selected.

Figure 3. Choosing a server role.

The User Mapping page allows you to select the databases that the login will have access to. When the Map check box is selected for a database, the Default Schema and User cells are enabled. The default schema is the schema that will contain the database objects created by the login. The login can create objects in schemas other than the default if the login has permission to use the other schemas. If no schema is specified, the default schema is used. The default schema also comes into play when you’re retrieving database objects. If no schema is specified on database retrievals, the default schema is searched first for the database object. If no Default Schema is specified on the Database Access screen, the default schema is set to dbo. The User data entry area allows you to enter a database username that is different from the login name. By default, the database username is the same as the login name, but you can change it.

The other thing that happens when you select the Map check box on the database is that the list of database roles is enabled in the bottom portion of the screen. You can select one or more database roles for the login. Both fixed and user-defined database roles are available for selection. The public database role is selected by default and cannot be deselected.

The Securables page allows you to select server objects for login permissions. The server objects are limited to object types scoped at the server level. They include Servers, Endpoints, Logins, and Server Roles object types.

The last page listed for selection is the Status page, which allows you to configure some authorization and authentication options. You can grant or deny access to the database engine on this page, and you can enable or disable the login. You also might need to visit this page if the login gets locked out. If this happens, you have an option on this page to reenable the login so that it is not longer locked out.

To modify a login, you right-click the login in the Security node and select Properties. The same set of property pages available when you create a new login are displayed. You cannot change the authentication mode after the login has been created, but you can change all the other settings, if desired.

To delete a login, you right-click the login and select Delete. The Delete Object screen appears, and you can click OK to delete the login. A warning message appears, stating “Deleting server logins does not delete the database users associated with the logins.” If the login has associated database users, and the login deletion is performed, database users are orphaned, and you have to manually delete the users associated with the login in each database.

Using T-SQL to Manage Logins

You can manage logins by using T-SQL statements. This approach is generally not as easy as using the user-friendly GUI screens that come with SSMS, but sometimes using T-SQL is better. For example, with installations and upgrades that involve changes to logins, you can use T-SQL to script the changes and produce a repeatable process.

SQL Server 2008 includes system stored procedures and an ALTER LOGIN statement that you can use to manage logins. The same system stored procedures available in prior versions are still available in SQL Server 2008, but they have been deprecated and will not be available in a future version. Table 1 lists the available system stored procedures and the basic function and current state of each one. The state indicates whether the procedure has been deprecated and whether an alternative exists in SQL Server 2008.

The system stored procedures have a variety of parameters, which are documented in Books Online. Because they have been deprecated, they are not the focus of this section. Instead, this section focuses on a number of examples that utilize the CREATE, ALTER, and DROP statements. The following example creates a SQL Server login with a password that must be changed the first time the login connects:

CREATE LOGIN Laura WITH PASSWORD=N'mypassw0rd$'
   MUST_CHANGE, CHECK_EXPIRATION=ON

You can then use the following ALTER LOGIN statement to change the default database, language, and password for the new Laura login:

ALTER LOGIN [Laura] WITH
 DEFAULT_DATABASE=[AdventureWorks2008],
 DEFAULT_LANGUAGE=[British],
 PASSWORD=N'myStr0ngPW'

Finally, you can drop the Laura login by using the following:

DROP LOGIN [Laura]

As you can see, the T-SQL statements for Logins are relatively easy to use. To simplify matters, you can generate T-SQL statements from SSMS. To do so, you click the Script button available on the screen that appears after you specify a login action. For example, if you right-click a login and select Delete, the Delete Object screen appears. At the top of this screen is a Script button. When you click this button, SSMS scripts the related T-SQL statements into a query editor window for you to review and execute.